Rich Communication Services a.k.a. RCS is the set of specifications being driven by operator community under the GSMA umbrella. A goal is to get an edge over the OTT competition that network operators seem to be losing as of now to the likes of Whatsapp, Skype etc. Even though RCS shall provide same kind of services like the OTT providers viz. peer-to-peer chat, group chat, location updates, file transfer, capability exchange, voice/video calls etc.—yet network operators have an edge as compared to their OTT providers in terms of leveraging their network infrastructure to provide quality of service, conferencing services or any other value adds that typically OTT providers may not be able to provide. Till the time RCS becomes a truly globally interoperable service like voice and SMS, the need to interwork with the OTT world will stay simply because most of the subscribers are not in the RCS world and operators having invested in RCS would like that end users use their RCS services and a network operator branded RCS client to the extent possible such that most or all of the communication needs are served by the RCS eco system.
This disclosure focuses on the aspect of extending the ‘RCS kind’ of experience to all the subscriber's buddies including the OTT or social contacts, buddies being served by other VoIP service providers, subscribers being served by enterprises—and thus not just restricting the RCS experience only to the RCS users—but most importantly by retaining the existing RCS clients and thereby implicitly asserting that there would be no new integration requirements between the RCS end point and the network to achieve the RCS and non RCS network (Social or otherwise) interoperability.
It should be noted here that the current RCS specifications do not state any ways or methodology of interworking with non RCS networks. However as stated before, this is an important business requirement given that it would still take few years for all the operators to implement RCS and the overall global GSM subscribers to see the day when RCS would truly be a globally interoperable service like that of Voice and SMS. Until that happens, an efficient and optimal architecture has to be in place which could easily fit in the standards based architecture and which protects the existing operator investments in IMS and RCS elements but still is capable of extending the reach of RCS subscribers to other non RCS subscribers.
In context of above, some limitations of the existing RCS specifications are summarized below:
1. Inability to interwork with non RCS networks that would include other packet switched VoIP networks and social networks that provide service mix similar to what RCS network provides to its users.
2. Limitations imposed by the virtue of endorsement of specifications from other standard bodies that limits the possibility of interworking with non RCS networks.
For example, OMA CAB specifications and vCard specifications do not specify a methodical way to define service provider's parameters serving the particular contact. Because of this, the RCS systems do not have any mechanism where-in non RCS contacts could be identified and processed accordingly.
Moreover, to enable communication between RCS and non RCS networks, the most important aspect is how the addressing and routing of non RCS entity that is being served by another service provider is handled.
Until few years back when only circuit switched voice services were offered by the Telco's, a MSISDN or an E.164 identity of a contact would suffice to offer this type of service. Further, the routing of the call related data (signaling and media) based on the service provider serving the contact would be handled by the core network elements like MSCs itself.
Now with the current evolution, services on a packet switched network have to be offered and sessions need to be routed to the appropriate service provider serving the contact. In an all IP world, this routing decision based on the service provider serving the contact should not be rested in the core network elements. Also the existing specifications do not specify the information in the depth required to be captured to ensure proper interworking with the service provider that is essential for technical realization.
The present disclosure proposes unique system and method that would address all the above limitations and would enable RCS networks to interwork with non RCS networks while retaining the existing RCS investments like RCS client and RCS core network elements that are realized based on the published RCS specifications (RCS 5.2) as on the date of writing the present specifications.
Some of the aspects of the present disclosure aimed to address one or more problems of the prior art or to at least provide a useful alternative are described herein below:
An aspect of the present disclosure is to provide system and method which would enable a communication between RCS and Non-RCS users in a seamless and transparent manner.
Further aspect of the present disclosure is to provide systems and methods that purposefully operates within the ambit of existing set of RCS and RCS endorsed specifications to achieve the interworking by integrating with the existing standards based network elements and with all the end users participating in the communication session using their existing client devices which would not need any software modifications at the client side to support the new interworking scenarios.
Yet another aspect of the present disclosure is to extend all the “applicable” RCS services to the Non-RCS users in a seamless and transparent manner.
Still another aspect of the present disclosure is to extend the operator hosted services like conferencing including the ability to control the conferencing attributes to all the non-RCS users in a seamless and transparent manner.
Other aspects and advantages of the present disclosure will be more apparent from the following description when read in conjunction with the accompanying figures, which are not intended to limit the scope of the present disclosure.